Notes

Outline

Object-Oriented and Classical Software Engineering   Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu

CHAPTER 8

Overview Reuse concepts Impediments to reuse Reuse case studies Objects and reuse Reuse during the design and implementation phases Reuse and maintenance Portability Techniques for achieving portability Interoperability

Reuse Concepts Two types of reuse Accidental reuse First, product is built Then, parts put into part database for reuse Planned reuse First, reusable parts are constructed Then, products are built using these parts

Why reuse? Minor Reason It is expensive to design, implement, test, and    document software Only 15% of new code serves an original purpose (average) Reuse of parts saves Design costs Implementation costs Testing costs Documentation costs Major Reason Maintenance Maintenance consumes two-thirds of software cost

Impediments to Reuse Not invented here (NIH) syndrome Concerns about faults in potentially reusable routines Storage–retrieval Cost of reuse

What sort of reuse rates can we expect? Theoretical maximum is 85% What can we get in practice? Consider case studies (1975 through 2000)

Raytheon Missile Systems Division Data-processing software Planned reuse of Designs 6 code templates COBOL code 3200 reusable modules Reuse rate 60% (1976–1982)

Toshiba Fuchu Works, Tokyo Industrial process control systems Accidental reuse of Specifications Designs Modules Contracts Manuals Standards Reuse rate (1985) 33% design 48% code

NASA Software Ground support system for unmanned spacecraft control Management permitted (but did not encourage) accidental reuse Accidental reuse of Modules Reuse rate (1982) 28% reused unchanged 10% reused with minor changes

GTE Data Services Data-processing software Strongly encouraged by management Cash incentives when module was accepted for reuse Cash incentive when module was reused Accidental reuse of Modules Reuse rate (1988) 15% reused code, $1.5 million saved (est. 1989) 20% reused code (est. 1993) 50% reused code

Hewlett-Packard Implemented in many divisions of the company Software Technology Division Accidental reuse of resource planning software 4.1 faults per KLOC of new code, 0.9 for reused code Overall fault rate decreased 51% Productivity increased 57% Cost $1 million, savings $4.1 million (1983–92)

Hewlett-Packard (contd) San Diego Technical Graphics (STG) Planned reuse of firmware for printers Cost $2.6 million, savings $5.6 million (1987–94) 24% reduction in faults 40% increase in productivity Cost of developing reusable firmware—11% more Cost of reusing it—19% of developing from scratch

European Space Agency Ariane 5 rocket blew up 37 seconds after lift-off Cost: $500 million Reason: attempt to convert 64-but integer into 16-bit unsigned integer, without Ada exception handler On-board computers crashed, so did rocket Conversion was unnecessary Computations on the inertial reference system can stop 9 seconds before lift-off But, if there is a subsequent hold in countdown, it takes several hours to reset the inertial reference system Computations therefore continue 50 seconds into flight

European Space Agency (contd) Cause of problem Ten years before, it was mathematically proven that overflow was impossible—on the Ariane 4 Because of performance constraints, conversions that could not lead to overflow were left unprotected Software was used, unchanged and untested, on Ariane 5 But, the assumptions for the Ariane 4 no longer held Lesson Software developed in one context needs to be retested when integrated into another context

Size of Reused Components NASA Most reused components were small Toshiba Many large components were reused GTE Many large components were reused Reason A strong managerial commitment for reuse is needed

Objects and Reuse Claim of CS/D Ideal module has functional cohesion Problem The data on which the module operates We cannot reuse a module unless the data are identical

Objects and Reuse (contd) Claim of CS/D: Next best module has informational cohesion This is an object (an instance of a class) An object comprises both data and action This promotes reuse

Reuse During Design and Implementation Design reuse Library or toolkit Framework Design pattern Software architecture

Library or Toolkit Set of reusable routines Examples: Scientific software GUI class library or toolkit The user is responsible for the control logic (white in figure)

Application Framework Control logic of the design “Hot spots” (white in figure) Faster than reusing toolkit More of design is reused The logic is usually harder to design than the operations

Design Pattern A solution to a general design problem In the form of a set of interacting classes The classes need to be customized (white in figure)

Widget Generator Tool that uses the set of classes created by the widget generator

Abstract Factory Pattern Abstract classes and abstract (virtual) methods The interfaces between client and program and generator are abstract The application program is uncoupled from the specific operating system

Software Architecture Encompasses a wide variety of design issues, including: Organization in terms of components How those components interact

Reuse of Software Architecture Architecture reuse can lead to large-scale reuse One mechanism: Software product lines Case study: Hewlett-Packard printers (1995 to 1998) Person-hours to develop firmware decreased by a factor of 4 Time to develop firmware decreased by factor of 3 Reuse has increased to over 70% of components

Reuse and Maintenance Reuse impacts maintenance more than development Assumptions 30% of entire product reused unchanged 10% reused changed Savings during maintenance are nearly 18% Savings during development are about 9.3%

Objects and productivity Reuse achieved Not via modules with functional cohesion, but via objects (informational cohesion) [classes] In general Software costs have decreased Overall quality has improved Large products are essentially collection of smaller products

Difficulties and Problems Learning curve Particularly noticeable with GUI Problems with inheritance New subclass does not affect its superclass But, any change to a superclass affects all its subclasses Subclasses low in the inheritance tree can be huge (inherited attributes) Polymorphism and dynamic binding Maintenance problems were already discussed

Difficulties and Problems (contd) Advantages far outweigh the problems Numerous refereed (e.g., [Capper et al., 1994]) and informal (OOPSLA Addendum) reports

Portability Product P: Machine M1 Op. Sys. O1 Compiler C1 Need P': Machine M2 Op. Sys. O2 Compiler C2 P is portable if it is cheaper to port P than to write P' from scratch

Incompatibilities Hardware (disk, tape, characters, parity) Operating system (JCL, virtual memory) Numerical software (word size, Ada) Compiler FORTRAN Pascal COBOL C Ada C++ Java

Why Portability? Difficulties hampering portability One-off software Hardware incompatibility Lifetimes of software, hardware Multiple copy software Portability saves money!

Portability strategies Portable system software Isolate implementation-dependent pieces UNIX kernel, device-drivers Levels of abstraction Graphics

Portability Strategies (contd) Portable application software Use popular language Use popular operating system Adhere to language standards Avoid numerical incompatibilities Excellent documentation

Portability Strategies (contd) Portable data COBOL, Pascal versus ASCII files DBMS

Interoperability The mutual cooperation of object code From different vendors Written in different languages Running on different machines Example: Nation-wide network of ATMs Server runs database software Clients (ATMs) run C++ Communications software Security

COM Common Microsoft mechanism for all component services Within the same process Invocation Different processes on the same machine Interprocess communication Between different machines Remote process call (RPC)

How COM Is Implemented Each piece is implemented as a COM   component (“object”) Each component has one or more interfaces Each interface supports one or more functions (“methods”) The client calls the COM library and specifies The class of the component The specific interface The COM library instantiates the COM component

Warning COM uses object-oriented terminology Class Object Method However, COM is currently only object-based, not object-oriented

CORBA International standard architecture for object-oriented systems Object request broker (ORB) allows client to invoke a method of any object in the system “The mother of all client/server middleware”

Comparing COM and CORBA CORBA is an international standard Implemented on a wide variety of platforms COM is a Microsoft product Hard to use with non-Microsoft products Integration of COTS software is easier with COM Most COTS software is supplied by Microsoft CORBA is much simpler than COM

Future Trends in Interoperability COM and CORBA are currently the “big two” Other interoperability products may succeed, such as JavaBeans Web-based applications need to be integrated into client–server products XML (Extensible Markup Language) will probably play a major role